Tasks, authorisations and responsibilities

Many organisations have a comprehensive competency profile, the growth opportunities (in roles and salaries) and the available courses for roles and jobs. Such a profile is sometimes missing for test professionals, with the excuse that testing is a one-off activity for instance. It may be clear that this is not the case. This is why a written career structure is necessary for testers as well.

Training options

Since testing is a risk-mitigating measure, a tester is a risk in and of himself. If the test professional does not test correctly or adequately, certain risks cannot be resolved. As such, it is important for a tester to know not only what well structured testing is, but also what he is testing. Taking the definition of a product risk in account (see also Product Risk Analysis), the tester must have a feeling for the domain (damage part) and the technology (chance of failure part) on which the system is based. He must master them and know where the risks are generally (e.g. that one calculation or that one specifi c combination of architecture and hardware). Concretely, this means that testers, too, can (must) attend courses relating to e.g. the tool that is used for programming or the domain for which the solution is being built.

Workplace location

Because testing is at the crossroads of many professions, testers have a lot of contacts with the professionals in these disciplines. Putting the testers in the middle is killing two birds with one stone. Their image is that they are truly at the crossroads, and there they have a lot of contacts. There are examples of an improved test process after the test team physically moved to the ‘centre’ of the organisation. Among other things, it improved the mutual respect between programmers and testers, which in turn had a positive impact on quality.

Reviews

Reviews are generally performed by a superior with experience in the tasks executed by the person reviewed. This is the only way to  achieve an objective picture of the past period and reach agreements. It is done this way in many IT disciplines. A programmer, for instance, is assessed by a project leader who used to work in programming himself. An information analyst is assessed by a business analyst with a similar past. Testers are often reviewed by the project leader. In his current role he has a lot to do with it, but he was never a tester himself. To avoid any suspicion of conflicting interests, a tester should be assessed by a superior or immediate stakeholder with actual testing experience. For instance the test coordinator or test manager.

Compensation

One current trend is to offer a variable salary in addition to a fixed salary. The size of the variable component (bonus) depends on the realisation of certain objectives (Key Performance Indicators or KPIs). A tester in an organisation has different interests than e.g. an information analyst, programmer or project leader. A test professional must be held accountable for other results. The situation in which everyone (including the tester) is held accountable for achieving the project planning is not ideal. The tester is at the end of the workfl ow and is often – incorrectly – perceived as the one causing the delays. It is better to assess a tester on the basis of his work’s results. Examples are achieving his planning for one test cycle or the number of incidents during production. Clearly, a number of principles apply in this context. Never award a bonus to a tester for the number of defects detected, because this depends on the quality of the software (and is therefore someone else’s point of concern).